Hey @sakshichitnis27, thanks for picking this up — closing the async hiredis-packing gap from #4176 is worth doing, and the layering is right. One blocker before we can merge, plus a couple of follow-ups.

Blocker: the hiredis path ignores the connection encoder, so it always encodes str as UTF-8. Async currently honors a custom encoding (e.g. encoding="latin-1" packs café as caf\xe9); with this change and hiredis installed it becomes caf\xc3\xa9. That silently changes the bytes written to Redis for anyone using a non-UTF-8 encoding, so it isn't a no-op / "no public API changed" as the description states. Please preserve the existing behavior — either fall back to the Python packer when encoding isn't the default, or pre-encode the args through the connection encoder before calling hiredis.pack_command — and add a regression test that covers a non-UTF-8 encoding, under both protocols.

Two follow-ups: (1) the new async HiredisRespSerializer diverges from the sync one (fallback-based, different memoryview handling) — let's settle the shared-vs-separate question you raised in the issue and, ideally, share one implementation; (2) the current tests monkeypatch hiredis.pack_command, so they don't verify real wire output — an async equivalent of tests/test_connection.py::test_pack_command would lock it down. Note the sync HiredisRespSerializer has the same encoder gap, so the encoding fix likely belongs in both stacks.